The intelligent network (IN) and advanced intelligent network (AIN) were designed to provide additional services to telecommunications network subscribers. Examples of IN and AIN service include 800 number service, calling card verification service, line information database service, etc. Both the AIN and IN architecture moved the databases required to provide these services from the end office switching systems to database nodes, which are referred to in the SS7 network as service control points or SCPs.
Moving IN/AIN service databases to SCPs simplified switching system architecture and allowed services to be modified or updated at the SCPs without modification of each end office switching system served by the SCPs. However, triggers, usually implemented in software, were required to be set at each SSP in order to access IN/AIN services. For example, if a particular subscriber wished to access an AIN service, a trigger would be required to be manually set at the end office serving that subscriber in order to allow the subscriber to access the service. Requiring triggers to be set at end offices places a heavy burden on switching system operators, since these triggers must be provisioned for each subscriber and each service at each end office.
Another problem with providing trigger-based services is that they require database queries, which increase network traffic and call setup time. For example, when a subscriber initiates a call, and that party's end office detects that IN/AIN service is required, the end office launches-a transaction capabilities application part (TCAP) query to an SCP. A signal transfer point receives the TCAP query, and routes the TCAP query to the SCP. The SCP formulates a TCAP response and forwards the response back to the end office through the STP. From the time that the query is launched until the response is received, call processing is suspended at the end office, which increases call setup time. In addition, the TCAP query and response messages increase network traffic.
In order to alleviate the problem associated with triggered network services, some triggerless network services have been developed. For example, commonly-assigned, co-pending international patent publication number WO 00/60839, published Oct. 12, 2000, discusses a triggerless number portability solution in which a signal transfer point performs number portability database lookups based on call setup messages received from end offices without requiring triggers at the end offices. While this solution greatly reduces the time required for number portability lookups, there still exists a need for providing other types of triggerless IN-services, such as screening services. As used herein, the phrase “screening services” includes services based on screening one or more parameters in a call setup message. Examples of such screening services include calling number screening, point code screening, credit limit screening, and a variety of other screening services. These screening services have either not been previously provided or have been provided only using triggers or end-office-based network implementations.
In connection with providing triggerless call screening services, there is currently no standard method for notifying a calling or called party end office or other node of the result of a screening action. Unless a screening action is performed by a particular end office, that end office may not know of the result of a screening action that occurred elsewhere in the network. Information regarding the results of a screening action can be important, for example, for notifying a called or calling party of the result of the screening action or for redirecting a call to another location. Accordingly, there exists a long-felt need for methods and systems for communicating call screening results to end offices or other nodes that did not perform the screening action.